Taskboards

This area allows you to define settings and workflow options for Access Requests and Reviews.

Access Requests

Settings Tab

This area allows you to determine which options are available within the Remediation/Change Management Taskboard.

Changing these options may affect access requests that were initiated within a currently open review.

Friendly Reminder: When you've finished making changes, select the Save button. If you forget to save your changes before leaving this page, your changes will be lost.

Actions
Option	Description
View Risk Ratings	Allows you to determine whether reviewers are able to see the risk ratings assigned to each privilege. By default, this field is set to "Nobody" meaning risk ratings will not be displayed to anyone. To change this setting: Select View Risk Ratings and then select a different option (Everyone, Security, or Trusted). When permitted, risk ratings are shown on the far-left column and are indicated by their associated color (see example below). Red - Critical Orange - High Green - Moderate Blue - Low
Can Act on Own Access Requests	Allows you to determine whether reviewers are able to take action on access requests associated with their own privileges. By default, this field is set to "Everyone" meaning everyone will be able to take action on access requests associated with their own privileges. To change who can take action on requests relating to their own permissions: Select Can Act on Own Access Requests and then select a different option (Security, Trusted, or Nobody). Anyone who is restricted from reviewing their own permissions will see the approval restriction message displayed in the Review Buttons area of the Remediations/Change Management Taskboard (see picture below).
Always show a warning message even if the user can act	This option works in conjunction with the Can Approve Own Access Requests option. When this option is selected, anyone who is allowed to take action on access requests related to their own permissions will see the following warning message displayed in the Review Buttons area of the Remediations/Change Management Taskboard (see picture below). Selecting the I understand and wish to continue link at the bottom of this message allows the Provision Engineer to continue reviewing their own permissions and take action as needed.

Notifications
Option	Description
Send an email alert when an access request is created	Select this option if you want to enable automatic email notifications for the Provision Team. If selected, email notifications will be sent to the email address in the Default Access Request Email field when an access request is created. SMTP settings must be defined and enabled within the System Configuration > Email page in order for Permission Assist to send notifications.
Default Access Request email	When the "Send an email alert when an access request is created" option is selected, use this field to specify the email address to which access request notifications are sent by default. This setting can be overridden at the application level (Manage > Applications > selected an application > Application Details page > Responsibilities tab > Remediation Alert Email)
Add remediation details attachment	Select this option if you want to send detailed remediation information within the email notifications that get sent to Provision Engineers. This can be helpful if you're sending remediation notifications to an internal help desk team that doesn't have access to Permission Assist. When selected, this option will attach a detailed report of the remediation access request to the email notification (see sample below).

Workflow Tab

The Workflow tab allows you to define the corrective control policies for access requests. This is helpful when you have policies within your organization that require approval for changes in certain situations. These are just a few examples of when you may want to set up corrective control policies:

You want to ensure someone approves an access request before it gets sent to the Provision Team
You want to ensure someone verifies that access request changes were completed correctly
You want people within certain roles to pre-approve or verify access requests that a specified level of risk

Examples:
- You can set up a policy that requires an application owner to pre-approve any request related to a critical application
- You can set up a policy that requires a supervisor or department manager to approve requests that involve changes to critical permissions.

To create a corrective control, enter information into each field as described below:

Field

Description

Add [allowed watchers]

Determines the type of corrective control that's being created. Select this field to select one of the following options:

allowed watchers - this option is selected by default; when this option is selected, the policy will allow the selected role to view access requests
approver - when this option is selected, the policy will require the selected role to approve access requests before they are sent to the Provision Team
verifyer - when this option is selected, the policy will require the selected role to verify that the changes have been made properly before access requests are completed.

rule for [Security Team]

Determines which role is required by the corrective control policy. Select this field to pick the role.

Add Rule link

When the policy is defined as you would like it to be, select the Add Rule link to add the rule below, where it can be further defined.

Allowed Watchers

This area displays the "allowed watchers" rules/policies that have been added. Allowed watchers are able to view access requests, but they are not able to take action on requests unless they have another authority that would allow them to take action.

For each required control, enter information in the following fields as needed to define requirements:

Field	Description
Are [always]	This field allows you to determine whether the selected role is always able or conditionally able to view access requests. Select this field to select one of the following options: Always - By default, this field is set to "always", which means a person in this role is always able to view access requests. Conditionally - When this option is selected, a person in this role is able to view access requests if certain conditions are met. For example, if you want a Department Manager to be able to view access requests that involve to critical applications or privileges, select "conditionally" to further define the rule.
required if present	Allowed watchers are always considered "required if present" which means the rule will apply unless the selected role doesn't exist. For example, if you add a rule that says the Department Manager is an allowed watcher, the rule will only be enforced if a Department Manager has been defined.
when the [application]	This field appears when the "Are [always]" field is changed to "conditionally". By default, this field is set to "application" which means that the role is able to view access requests when an application has a certain priority level (defined in the "has a priority of" field) or higher. If this field is set to "privilege", the role is able to view access requests when a privilege has a certain priority level (defined in the "has a priority of" field) or higher.
has a priority of [None]	This field appears when the "Are [always]" field is changed to "conditionally". By default, this field is set to "None" which means the role is able to view access requests when the application or privilege has a priority/risk rating of "None" or higher. If you'd like the role to view applications or privileges of a specific priority or higher, select [None] and then select a priority level from the drop-down list.

Pre-Work Approval

This area displays the "pre-work approval" rules/policies that have been added. For each required control, enter information into the following fields as needed to define requirements:

Field	Description
At least [one]	NOTE: This option is not available when adding rules for Supervisors, Area Reviewers, Reporters, or any of the Defined Managers. When adding a new rule, this field is set to "one" by default which means that at least one person within this role is required. Some roles allow you to add two roles. To require two people within the role, select [one] and then select two from the drop-down list. Selecting "two" ensures that at least two people within the role will pre-approve each access request. For example, if you have 5 people within your Security Team, and you want to ensure that at least 2 of the 5 pre-approve access requests, set this field to "two".
Is/Are [always]	This field allows you to determine whether pre-approval is always required or conditionally required. Always - By default, this field is set to "always", which means a person in this role must approve access requests before the Provision Team member is able to take action. Conditionally - When this option is selected, a person in this role must pre-approve access requests, but only if certain conditions are met. For example, if you want a Department Manager to pre-approve any access requests that involve critical permissions, set this field to "conditionally" and then complete the other fields as needed. NOTE: Permissions must be risk rated before the review is started in order for this control to be applied properly.
Required	This field is set to "required" and is the only option available for Security Team members; however, other roles may be considered either required and/or required if present. Required - When this option is selected, a person in this role must pre-approve access requests as defined by the rule without any exceptions. For example, let's say a rule requires one Application Manager to always pre-approve access requests. If an access request is created for an application that doesn't have an application manager, one will need to be assigned in order for the request to be pre-approved. The pre-approval process cannot be skipped and other roles, such as the Security Team, cannot take the responsibility for pre-approal in place of an Application Manager. Required if present - When this option is selected, people within the role are only required to pre-approve requests if someone exists within the role. The policy will not be enforced if a person within the role does not exist.
When the [application]	This field appears when the "Is/Are [always]" field is changed to "conditionally". Select one of the following options: Application - by default, this field is set to "application" which means that a person within the role is required to pre-approve requests when the request relates to an application that has a certain priority level (defined in the "has a priority of" field) or higher. Privilege - If you'd like someone within the role to pre-approve requests only when a user has access to privileges of a certain priority, select [application] and then select privilege from the drop-down list.
has a priority of [None]	This field appears when the "Is/Are [always]" field is changed to "conditionally". By default, this field is set to "None" which means the members of this role are required to pre-approve requests when the application or privilege has a priority/risk rating of "None" or higher. If you'd like them to pre-approve applications or privileges of a specific priority, select [None] and then select the priority level from the drop-down list.

Post-Work Verification

This area displays the "post work verification" rules/policies that have been added. For each required control, enter information into the following fields as needed to define requirements:

Field	Description
At least [one]	NOTE: This option is not available when adding rules for Supervisors, Area Reviewers, Reporters, or any of the Defined Managers. When adding a new rule, this field is set to "one" by default which means that at least one person within this role is required. Some roles allow you to add two roles. To require two people within the role, select [one] and then select two from the drop-down list. Selecting "two" ensures that at least two people within the role will verify each access request after the Provision Team has completed their work. For example, if you have 3 people within your Security Team, and you want to ensure that at least 2 of the 3 verify each access request that involves critical permissions, set this field to "two".
Is/Are [always]	This field allows you to determine whether post-verification is always required or conditionally required. Always - By default, this field is set to "always", which means a person in this role must verify access requests after the Provision Team member completes their work. Conditionally - When this option is selected, a person in this role must verify access requests, but only if certain conditions are met. For example, if you want a Department Manager to verify any access requests that involve critical permissions, set this field to "conditionally" and then complete the other fields as needed. NOTE: Permissions must be risk rated before the review is started in order for this control to be applied properly.
Required	This field is set to "required" and is the only option available for Security Team members; however, other roles may be considered either required and/or required if present. Required - When this option is selected, a person in this role must verify access requests as defined by the rule without any exceptions. For example, let's say a rule requires a Department Manager to always verify access requests. If a Department Manager hasn't been assigned, one will need to be assigned in order for the request to be verified and completed. The verification process cannot be skipped and other roles, such as the Security Team, cannot take the responsibility for verification in place of the Department Manager. Required if present - When this option is selected, people within the role are only required to verify requests if someone exists within the role. The policy will not be enforced if a person within the role does not exist.
When the [application]	This field appears when the "Is/Are [always]" field is changed to "conditionally". Select one of the following options: Application - by default, this field is set to "application" which means that a person within the role is required to verify requests when the request relates to an application that has a certain priority level (defined in the "has a priority of" field) or higher. Privilege - If you'd like someone within the role to verify requests only when a user has access to privileges of a certain priority, select [application] and then select privilege from the drop-down list.
has a priority of [None]	This field appears when the "Is/Are [always]" field is changed to "conditionally". By default, this field is set to "None" which means the members of this role are required to verify when the application or privilege has a priority/risk rating of "None" or higher. If you'd like them to verify applications or privileges of a specific priority, select [None] and select the priority level from the drop-down list.

Reviews

Option	Description
Reassign Identity	Allows you to determine who is able to reassign identities within the review using the Reassign Identity option. By default, this field is set to "Everyone" meaning all Permission Assist users are able to reassign identities if needed. To restrict access to this option: Select Reassign Identity and then select a different option (Nobody, Security, or Trusted).
Reassign Review Supervisor	Allows you to determine who is able to reassign supervisors within the review using the Reassign Supervisor option. By default, this field is set to "Everyone" meaning all Permission Assist users are able to reassign supervisors if needed. To restrict access to this option: Select Reassign Review Supervisor and then select a different option (Nobody, Security, or Trusted).
Add Reviewer	Allows you to determine who is able to invite someone into the review to comment on or take action on review items as a specific role. For example, if a supervisor normally reviews their direct reports, but they would like to invite their department manager or application owner to comment on or review a specific item, they can add a reviewer to the review item so that person can take action as needed. By default, this field is set to "Everyone" meaning all Permission Assist users are able to add reviewers to review items. To restrict access to this option: Select Add Reviewer and then select a different option (Nobody, Security, or Trusted).
View Risk Ratings	Allows you to determine who is able to see the risk ratings assigned to each privilege. By default, this field is set to "Nobody" meaning risk ratings will not be displayed to anyone. To change this setting: Select View Risk Ratings and then select a different option (Everyone, Security, or Trusted). When permitted, risk ratings are shown on the far-left column and indicated by their associated color (see example below). Red - Critical orange - High Green - Moderate Blue - Low
View Pre-Approved Review Items	Allows you to determine whether reviewers are able to see pre-approved items within the Review Items Taskboard. By default, this field is set to "Everyone" meaning everyone will be able to see pre-approved items. To change who can see pre-approved items: Select View Pre-Approved Review Items and then select a different option (Security, Trusted, or Nobody).
Can Approve Own Review Items	Allows you to determine whether reviewers are able to take action on (approve or flag) their own permissions. By default, this field is set to "Everyone" meaning everyone will be able to review and approve or flag their own permissions. To change who can review their own permissions: Select Can Approve Own Review Items and then select a different option (Security, Trusted, or Nobody) Reviewers that are restricted from reviewing their own permissions will see the approval restriction message displayed in the Review Buttons area of the Review Items Taskboard (see picture below).
Always show a warning message even if the user can act	This option works in conjunction with the Can Approve Own Review Items option. When this option is selected, reviewers that are allowed to take action on their own permissions will see the following warning message displayed in the Review Buttons area of the Review Items Taskboard (see picture below). Selecting the I understand and wish to continue link at the bottom of this message allows the reviewer to continue reviewing their own permissions and take action as needed.

Starting Remediation

These settings determine workflows for the remediation process.

Forced	Select this option if you want review items to be immediately sent to remediation if they are flagged. When this option is selected, no manual action is needed to send the item to remediation.
Optional	Select this option if you want reviewers to be able to flag review items without immediately sending the item to remediation. When this option is selected, the reviewer will need to manually start the remediation process.
None	Hides all remediation options. Select this option if you want to handle remediation outside of Permission Assist. Review items can still be flagged and comments may be used to indicate items are sent to remediation.
Limit the remediation workflow to only show assigned permissions or ones allowed by matching entitlement roles	When reviewers request that a user's permissions be changed, they're given the ability to request both the removal of existing privileges as well as the addition of new privileges. If you'd like to prevent reviewers from requesting additional privileges during the review process, select this option. When this option is selected, reviewers will still have ability to request the removal of existing privileges, but they will not be able to request new permissions unless they are allowed based to the user's Entitlement Role.